Business Analyst Community & Resources | Modern Analyst

Upside down Procedures and Processes

Mike Cunningham — Wed, 27 Jul 2011 12:00:00 GMT

Are we looking at it all wrong?

Do you ever get the feeling that you are seeing something very different than the other guy? I don’t just mean the glass half full/empty outlook on life, but fundamentally are we looking at things the wrong way?

I sometimes get that feeling when dealing with projects that involve processes, and all my projects are about processes! Take the following scenario, the stakeholder or client has a problem; they know they need to improve some processes in the organization, but are not sure exactly where to begin.

As the designated Agent of Change we provide them with guidance to determine goals and objectives to scope out the next steps. For example:

· Need to document existing processes accurately

· Train existing staff how to follow these processes

· Be able to standardize the process for quality and efficiency

Before I continue, let’s go back in time …

Back to the Future

In 1770, James Watt pioneered the use of drawn-to-scale engineering plans for the manufacture and installation of industrial products1[. These were used to assist in the successful deployment of his products; steam engines for factories driving the industrial revolution. Over time these plans evolved from crude drawings to assist an experienced engineer to more detailed plans that were created by a junior draftsman. This was the forerunner of today’s Computer Aided Design ]2[ world. Detailed, precise instructions permitted products to be manufactured without the need for hugely skilled labor, and a bridge was created between design and production engineering.

In many ways the Subject Matter Expert/Project Manager takes the same role today as those early engineers. Understanding in detail what needs to be done, and translating these complex processes by way of underlying skills, experience and well established methodologies.

The time may be right to go back and look at a different way of doing things; one that may change industry again.

Looking at the pie instead of the ingredients?

When an expert looks at a problem they often want to show off their skills. Look at me I am smart, indispensible, letters after my name, better than you … got the idea. Now all project managers are not this way, but there is a tendency to want to show off our skills versus others in the project.

One way this happens is we often/always start looking at process FIRST. Because we are good at seeing the big picture, grasping the complex, overanalyzing the simple; so we habitually start with the complete process.

As a result we are often way ahead of where the client/stakeholder is in the project. Being ahead a few steps is probably OK; being so far ahead they can’t see your dust creates distance, misunderstanding and communication problems. They may not feel that you are on the same wavelength, and we all know where that leads. We don’t want to go there.

Start with the tasks, not the process.

Recently, I have been examining this problem with some precision. I know Business Process Management has the word process in the middle, and is therefore important. However, every process is full of tasks, activities and decisions. The client/stakeholder may not yet see how all these tasks are intertwined to make up their own work processes, but they understand the basis of all processes are tasks. So why don’t we start by capturing the tasks first? Good idea!

A task centric approach has several advantages over process first. These include:

1. It’s easier to get the client/stakeholder to capture precise information about roles, ownership, guidelines, resources, timeframes, frequency etc. on a task basis

2. Once you have all the important tasks documented it’s easier to then order them for the “as is” or “current state” of operations

3. Get everyone on the same page for the process documentation project

4. Builds a base of foundation data for the project

Once this task library has been created, we can return to the process view. However now we have the details we need to build on our “Discovery” phase of the project. If you have used Excel or a similar product to capture this information, it will be easily sorted and can be then categorized for the process capture stage of the project.

Conclusions

Just as we learn the alphabet, words, sentences, grammar before creating great prose; we need to apply the same principles to our Process Management activities. Taking logical steps to breakdown the “Discovery” process into tasks and then build the jigsaw puzzle that is the process makes sense.

Given the potential for re-use of tasks in best practice models, this approach may have much merit in Process Improvement methods.

]1[ NMSI. The Production Process. May 20, 2011. http://www.ingenious.org.uk/Read/Seeing/Drawings/Theproductionprocess/.

]2[ Wikipedia. Computer-aided Design. May 20, 2011. http://en.wikipedia.org/wiki/Computer-aided_design.

]

Asking the Right questions-Process Discovery

Mike Cunningham — Mon, 14 Feb 2011 12:57:00 GMT

If you are an internal Business Analyst or consultant asking the right questions in a Discovery project is a critical skill. While it seems that a 10 or 20 year veteran seemingly gets those answers by some magical power, it’s really not that complicated. The experienced Business Analyst or Project Manager has been there many times before and knows how to build an good set of probing questions that will bring out the details.

For process discovery, you may already be a subject matter expert on the project, but often that’s not the case. In these situations creating a shopping list of items that will guide you to ask the right questions is very important. This list includes:

Identification of roles of those involved
Responsibilities for actions/tasks and decisions in the process
Outcomes and results from the processes in hand
Known problems with existing processes
Goals from management required from the Discovery project
The expertise level of the intended audience
Access to quality standards for the existing process
Clear separation of “current state” from “future state” questions
Identification of resources, guidelines and instruction locations and usage

This list can go on, but you get the idea. Unless you identify, who, what, how and when before you start the interview or information gathering process, you many need to re-interview staff because of your unpreparedness. Not a good idea. Plan your questions carefully, particularly when it comes to the interview stage of your Process Discovery project.

Original posted at Michael Cunningham's BPM Blog

Asking the Right questions-Process Discovery

Mike Cunningham — Fri, 21 Jan 2011 12:57:00 GMT

Identification of roles of those involved
Responsibilities for actions/tasks and decisions in the process
Outcomes and results from the processes in hand
Known problems with existing processes
Goals from management required from the Discovery project
The expertise level of the intended audience
Access to quality standards for the existing process
Clear separation of “current state” from “future state” questions
Identification of resources, guidelines and instruction locations and usage

Original posted at Michael Cunningham's BPM Blog